【レポート】『はじめてのCircleCI 第10回』に参加しました。 #CircleCIJP

2020年7月9日に行われたCircleCIユーザーコミュニティのオンラインイベントである「はじめてのCircleCI」のイベントレポートです。

#イベント

#初心者向け

#CircleCI

#CI

#レポート

石橋勇二

2020.07.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

皆さんこんにちは。[石橋]https://twitter.com/1484_yuji)です。昨日参加させて頂いた、CircleCIユーザーコミュニティのオンラインイベントである「はじめてのCircleCI」のイベントレポートを書かせて頂きます。

はじめてのCircleCI 第10回

イベント概要

今回は、CI/CDは知っているけど、

CI/CDのより詳しい情報を集めている方
CircleCIを触ったことがないが試してみたい方
DevOpsを社内に浸透させようとしている方

向けのオンラインセミナーという形で行われました。

CircleCIとは

世界最大規模のクラウドCI/CDサービス
より良いコードをより速く、簡単にリリースすることを可能にする
2011年設立、サンフランシスコ本社、300人以上の社員(米国、東京、英国にオフィス)
2500万の月間ジョブ(2017年時点では300万件)(伸びがすごい！！)
50万人以上のCircleCIを使用する開発者数(2017年時点では17.5万人)(伸びがすごい！！)
日本でも多くの企業での導入事例
日本語でのサポート
日本語のドキュメント
世界中のユーザーコミュニティ

Why CI/CD

CI/CDとは

CI (Continuous Integration / 継続的インテグレーション)

What?
- 全ての開発者が共有リポジトリにコミットを積み重ね、全てのコミットをトリガーにしてビルドとテストを繰り返すこと。
- これによりテストに失敗した場合に素早く修正することが可能となる。
Why?
- チームの生産性・効率・満足度をあげるため。
- 品質を上げ、スピードを上げ、より安定した製品を生み出すため。
CIでできること
- コードのビルド、静的コード解析、単体テスト、結合テスト、結合テスト、脆弱性チェック、テストサマリー
CIが解決する問題
- 全てのコミットに対してCIする
- 早い段階でバグを発見できる
- 設定でテスト・ビルドを制御可能
- 静的解析などで標準化
- コードの品質UP
- テスト失敗したコードのマージブロック
- masterブランチの安全保証

CD (Continuous Delivery / 継続的デリバリ)

(狭義の)Continuous Deliverly(継続的デリバリー)
- 常にリリース可能な状態を維持する
- リリース作業に人間の意思が介在する

Continuous Deployment(継続的デプロイメント)
- 自動でステージング・本番環境へデプロイする
- リリース作業に人間の意思が介在しない

CI/CDに関する資料

Puppet: State of DevOps Report 2018

業績の良い会社はテストパターンやデプロイパターンの再利用が多い

エンジニアリングの効率化に欠かせない5つの測定指標

Commit-to-Deploy Time(CDT)
- コードがコミットされてからデプロイされるまでの時間
Build Time
- CIビルドにかかる時間
Queue Time
- CIビルドが始まるまでに待たされる時間
How often Master is Red
- masterブランチが壊れている時間
エンジニアリングの間接コスト
- ツールのメンテナンスなど開発以外に掛かっている時間

CircleCIの3000万件のワークフローから得られたDevOpsに関する知見

Why CircleCI

CircleCIの概要

CircleCI機能や特徴

運用コスト・維持コスト削減
- 運用チームや自社環境の構築が不要(オンプレ版は必要)
- .circleci/config.ymlでテスト環境の統一
開発スピード向上
- Dockerサポートにより、高速にビルド環境を立ち上げ
- SSHデバック機能でビルドエラーの迅速な解決
- パラレルジョブ・マルチコンテナでキュー(待ち時間)を解消
- 複数のキャッシュ機能でビルドを高速化
- パイプラインでジョブを連結
パイプライン改善
- Orbs(configのパッケージ)を使って、簡単にビルドやテスト・デプロイが可能

Dockerサポート

circleciはネイティブでdockerをサポートしてる
vmによるciと比べて非常に高速にビルド環境を構築することが可能です。

.circleci/config.ymlでテスト環境を統一

個々のジョブ定義
- Dockerイメージの指定、ステップとしてコードの取得やテスト内容を記載
ジョブを組み合わせたワークフロー定義
- 連続実行、ファンアウト・ファンイン、スケジューリング、ブランチ別、タグ別など

CircleCIの思想

コンフィグはファイルに書かれるべき(コードと同じくレビューとバージョン管理を行う)
明示的であるべき
その結果のデメリットも
- 1から設定を書かないといけない
- 冗長になる

ワークフロー

ビルド設定を分解して、依存関係や並列処理を行うための機能
ワークフローのタイプ
- スケジューリング:ナイトリービルドのように決まった時刻に実行
- マニュアル承認:ワークフローの一部で自動実行を中断し、手動による承認によって再開
- ブランチ指定:特定のブランチへのコミットによって実行
- タグ指定:Gitのタグによって実行

SSHデバック

ビルドに失敗した場合など、SSHデバックをOnにして再実行することで、ビルド終了後2時間、もしくはSSHセッションが終わって10分間までは、コンテナを起動した状態で維持する

ビルドの高速化

ファイルの再利用
- 同一ジョブ間のキャッシュ
- ワークフローが繰り返し実行される中で、同一ジョブで利用される永続データを使い回す
- 同一ワークフロー内のデータの引き継ぎ
- 同一ワークフロー内の異なるジョブ間でデータを共有する

並列処理
- 並列に実行するジョブ数を制限することで、時間がかかるジョブがボトルネックにならない
リソースクラス
- ビルドを実行する環境(DockerやLinux)のスペックを調整できる
- vCPUやメモリなどの組み合わせを選択可能

設定パッケージングと再利用(Orbs)

Orbsとは、CircleCIの設定を再利用し、さらにそれを自由に配布する仕組み
Orbsを使うと他の人が書いたCircleCIの設定を自分のプロジェクトの.circleci/config.ymlに差し込むことができる。
OrbsはOrbsレジストリ上で誰でも公開することができ、他のユーザーが作ったOrbを誰でも使うことが可能
Orbsの種類
- Orbs Registry
- Certified(CircleCI)
- Partner(CircleCI認定パートナー)
- 3rd party(その他)